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From the General Manager’s Desk, 


Greetings.... Happy New Year to all our Jewish friends! Perhaps at this 
time of year Atari has chosen the best time to have a LANDMARK conference 
on CIS. In fact, we at ST REPORT believe so strongly that this is the 
right time, we have included many points to ponder about the future of the 
ST and Atari in general throughout this issue. We have done this so you 
have a concise source of good subject matter to build worthwhile questions 
for the "BIGWIGS" at Atari. 








Please make sure you ask YOUR question and do remember that NO question is 
a stupid question ....only someone who says a question is stupid is dumb! 
This is a rare opportunity for the Atari Userbase, Usergroups and 
potential business users. Use it to your best advantage! Ask those 
Questions that have been nagging you....the answers may surprise you. 





ONLY IN AMERICA! God, I love to brag about the USA! 


R.F.Mariano 








A CONFERENCE WITH THE PRESIDENT 



































ATARI TOP EXECS TO ATTEND PUBLIC FORUM 

















The Atari Forums on CompuServe will be sponsoring a world-wide electronic 
Teleconference with Sam Tramiel, President and Chief Operating Officer, 
Sig Hartmann, Executive Vice President and Software President of Atari 
Corporation and Neil Harris at the keyboards on Monday, September 26 at 
9:00pm EDT. Your participation in this conference is welcomed and 
encouraged! 











The Presidential Conference is going to be held in CompuServe’s 
Electronic Convention Center(tm). The Electronic Convention Center (tm) 
was designed specifically for special conferences of this nature and can 
have as many as 300 people participating simultaniously without causing 
the slightest speed decrease. In addition, the Electronic Convention 
Center(tm) offers the capability of holding a more structured 
conference, making it possible for you to ask your questions and be 
answered by the respondants without any interruptions. Top performance is 
absolutely guaranteed! Lastly, the Electronic Convention Center (tm) 
offers additional conveniences (discussed later in this text) that will 
make your participation in this conference amazingly easy. If you’ve 
participated in other national conferences of this type before and have 
been underwhelmed at the way it was conducted and the performance of the 
service during /’/heavy’ usage, this conference is your opportunity to 
experience the communication power of a professional-quality global 
information network. 



































ACCESSING THE CONVENTION CENTER 

















As mentioned above, the Presidential Conference will be held in 
CompuServe’s Electronic Convention Center(tm) -- NOT the conference area 
of the Atari 16-Bit Forum. To access the Convention Center, type GO 
CONVENTION at any CompuServe command prompt. 











When you type GO CONVENTION, CompuServe will display the following menu: 





Electronic Convention Center (tm) 








INFORMATION/RESERVATIONS 
1 Instructions 
2 List Conferences/Make Reservations 
3 Review/Cancel Reservations 
4 Conference Etiquette 














Enter choice ! 


Choice 1 allows you to view the complete instruction guide for using the 
Convention Center. Choice 2 and Choice 3 allow you to list upcoming 
special conferences and any advance "reservations" (NOT NECESSARY FOR 
THIS CONFERENCE!) you might have made. Lastly, choice 4 provides some 
information on the etiquette followed by participants in an electronic 
































conference. 
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Enter choice ! 


All you will need to do is select cho 


conference. 





Once you select choice 5, CompuServe 
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Enter your name and press a <CR> as s 
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ASKING A QUESTION 


Once the moderated conference begins, 


speaker will be allowed to openly communicate at all times. 


participants must signal that they wo 
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USING THE BUFFER 
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Here are the commands you will need to know in order to use the buffer 
feature of the Convention Center: 








/BUFFER EDIT - 











/BUFFER SEND - 








OTHER COMMANDS YOU SHOULD KNOW ABOUT 


Brings you into "edit" mode where you can 
II-upload, or edit your text. 


compose, ASC 


Send buffer to all 





participants. 











The following list of commands are available to you in the Convention 
























































Center: 

/BUFFER EDIT Edit text buffer /BUFFER SEND Send text buffer 
/BULLETIN Display short bulletin /COMMANDS Show list of commands 
/DAY Show date and time /DISPLAY Change message display 
/ECHO Show input /EXIT Exit the conference 
/NOECHO Do not show input /HELP Command help text 
/NAME Change your name /NOSEND Refuse private "sends" 
/OFF Log-off / SEND Send a private message 
/STATUS User/guest count /WHO Show last speaker 
/USERS List users 

/ LOOK Question status (how many people are in the queue) 

/ QUESTION Question request /UNQUEUE Cancel a question 


If you have any questions, plea 


Sysops of the Atari Forums. 














se feel free 


Otherwise, hope 





to post a message to the 
you found this introduction 


file useful and we’re looking forward to seeing you at the big 


conference! 
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Report, Ron Kovacs or Rex Reade 


Be sure to include your full mailing address so your 
Compuserve kit can be immediately mailed to you! 
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SPECIAL SUPRA MODEM OFFER!!! 




















CompuServe’s Atari Forums have made very special arrangements with 
Paramount Products Inc. to offer the members of our forums the chance to 
upgrade your system to 2400 baud service at a very special price. 


For a limited time, CompuServe subscribers may purchase the 


SUPRA CORP. 2400 baud Hayes-compatible modem 
for the very **LOW** price of just $139.95 !!!!! 


These are brand new, not reconditioned units, with the full SUPRA CORP. 
warranty. The SUPRA MODEM uses the Hayes Smartmodem '’AT’ command set and 
operates at 300-1200-2400 baud. It’s an outboard unit (not an internal 
plug-in card) allowing ease of transfer to other computers. 

Connection is thru the standard RS-232 interface. (Just plug it into the 
back of your ATARI ST). 





To take advantage of this special offer, Phone the 800 number 
listed below or write to: 





Paramount Products Inc. 
1405 S.E. Pacific Blvd. 
Albany, Oregon JTZ 1 





RARER Phone orders: (800) 444-4061 KEKER 
Price: $139.95 + shipping 
UPS ground: add $4.00 
UPS Blue label: add $8.00 
Cede add $2.25 


MasterCard or VISA accepted Orders will be shipped the next business day 


If you’ve been accessing CompuServe at 1200 baud, this is a great way 
to lower your total online bill since CIS does *NOT* charge a premium for 
2400 baud access. (You can get the same amount of information or download 
the same amount of programs in approximately 1/2 the time as 1200 baud 
users!) This modem will PAY FOR ITSELF in just a few sessions. 














INSIGHTS INTO THE FUTUR 
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by Michael Arthur 


In the computer user’s quest for more sophisticated machines that will do 
more, function better, and be easier to use, many options have appeared 
throughout the brief history of the microcomputer. For many, the answer, 


for some reason, has been IBM machines. For them, the future lies in many 
developments, like OS/2, but mainly in the 386 chip, which will carry them 
into the 1990’s. Some, though, have forsaken this route for a new type 

of user interface, using a new mechanism called a mouse, and using menus 
and windows and dialog boxes to use their machines much easier than what 
was previously available. Many of these people have chosen the Macintosh, 
which has the best implementation of this new way of using a computer, and 
has a pretty bright future, as Apple is VERY financially secure, and as 
products like Hypercard and the Mac II give performance that is equal or 
better than the IBM machines, resulting in that many people have stopped 
using them whenever possible, and do not prefer IBM’s to the Macintosh. 


























One thing about the Macintosh, though, is that is oftentimes too expensive 
for many people, and lacks features necessary in computers in all but the 
most expensive Macintosh, the Mac II. Many peripherals (mostly the ones 
made by Apple) and most of the software is also expensive, turning many 
people to look elsewhere. 





Some of these people have chosen the Amiga, with its amazing graphics, and 
built-in multitasking. The Amiga, though, does NOT have a Mac-like user 
interface that is preferable, and has a text-based user interface that is 
even worse than what was in IBM’s. Also, its multitasking operating system 


crashes a LOT, another thing that is never preferable. 








So many people look elsewhere, and see the Atari ST. 


It is VERY fast, has a user interface that is very good, which, although 
not better than Mac Finder, is good enough for most people. It also has 
many emulators out for it, a built-in MIDI interface, which makes it the 
ONLY choice for many professional musicians, and more built-in memory than 
ANY other computer. 











But after getting an ST, they find out that the ST also isn’t perfect, and 
that their fears about Atari itself may not be unfounded. 


Things like Federated, Atari’s relations with its dealers, Atari’s record 
of Vaporware, and the shoddy Developer’s Kit (something NEVER seen in 
companies like IBM; Atari says that upgrades, newsletters are sent very 
often to developers buying one, but....) have caused many otherwise loyal 
ST owners to openly protest Atari’s actions. These people have been called 
Atari Bashers, the most vocal of them said to be in a group called the 
Gang of Five. Such actions, though disagreeable and embarrassing to most 
ST users, who both hate to hear such negative things and despise having to 
SAY these things about Atari are forced to do so because it is the only 
way, (apparently), to obtain any kind of reaction from Atari that is 
evident. 























Even now, while Atari does an admirable job of keeping quiet about 
developments, ST users are being treated to excellent goodies both from 
Atari and third party developers and companies. 

Here are few of the fine treats to expect from Atari in near future..... 





IF any of the information presented is inaccurate, please remember th 
limited resources available for this article. Also, because of the lack 
of space, this article only focuses on the Atari hardware/software areas 
and developments that are certain to have an effect on the ST’s future. 











THE ATARI ST COMPUTER LINE 

















The ST, right now, has only support of 4 Megabytes, uses only an 8 MHZ 
68000, and supports graphics which, although they allow the ST to run at 
its fast rate, leaves much to be desired. 
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Atari HAS announced a 68030 add-on to the ST, known as the EST, though. 


It has 4 megs of RAM on board, uses a VME bus, supports the SUN Network 
File System, has SCSI/DMA ports, uses XWINDOWS with UNIX Version 5.3, and 


comes with an 80 Megabyte Hard Disk. 





It supports resolutions of 1280*960 in monochrome (and maybe 16 colors), a 
1024*768 display with 256 colors at the same time, and a 640*400 mode 
using the entire palette of 16 million colors, at the same time. 


The prototype is running at 16 MHZ, but it will sooner or later support 
20-24 MHZ and up. It will cost around 3500-5000 dollars, and will be 
officially announced at Winter Comdex. 








This will be one of the first computers of ANY kind to use the 68030, and 
the FIRST microcomputer to use it. But in the long run, it might not 
become that popular. 











After the initial reviews saying how powerful it is, how it supports more 
colors than previously seen in micros, and how reliable it is, (IF Atari 
wants it to sell, and if they are wise, they will boast about it’s 
reliablity and make sure the public knows....also, a GENEROUS warranty 
program is definately in order. 1 - 3 years! 

















1) Provide an adequate staff of knowledgable people for Customer Support 
who know more than just a general briefing given by a "marketing experts"! 
The only other solution would be to have a well-known third party who 
already makes and supports UNIX for several machines provide UNIX support, 











and cause the current staff of Technical Support to reflect the above 
type of knowledge concerning the hardware and software. This is 
mentioned because the NEW Technology will require expert Technical 











Support, and what Atari has in place at this time is totally inadequate 
and cannot properly fill this need. 





2) Advertise HEAVILY for this machine so people will consider it. We 
ALL know that Atari is not a household name in business computing, 
therefore it is encumbent upon Atari to properly promote the entire 

ST product line. At least, it’s ABOUT TIME! On these grounds, it might 
be hypothesized that Atari might not have a chance, and is wasting its 
time, but this computer WOULD show the business world that Atari makes 
much more than game machines. 











T 





IF Atari does a FEW things right, then the EST might have a shot at the 
VERY lucrative workstation market, and even become associated with the 
68030 like the Mac II is with the 68020. 











Portable ST 

Atari has also "hinted" at a Portable ST, which will have a 20 Megabyte 
hard disk, and a megabyte of memory. The Portable will probably come 
with features like a MIDI port, built-in floppy drive, the blitter chip 
and the new TOS ROMs. 





The display will come from another company, like Zenith, simply because 
"manufacturing LCD panels, where EVERY pixel must be operable, can strain 
the fabrication facilities of many companies." This is taken from the 
September issue of Byte, on page 246. And, while "prototypes are one 
thing, production runs are quite another", meaning that while Atari might 
have a prototype of the Portable ST ready and all might be well, when it 
comes time to produce the LCD screens, not even the new Atari Factory in 
Houston might be able to do it right at a cost that would make it 
feasible, and Atari will get another company to custom-make the panels 
for the Portable ST. 





























The Portable ST’s screen will probably use a rear-lighting, or backlit, 
LCD panel, to make it more readable, EVEN in bad lighting. LCD screens 
can display 640*400 screens, but ALSO support 320*200 and 640*200 
resolutions, without colors, of course. 

















Possiby, this ST will be able to switch from Low to Medium to High 
Resolution, and able to run both Low/Medium Resolution AND High 
Resolution software, with Patched TOS ROMs to make it work. 





IF Atari is wise, they will seriously consider using an LCD screen that 
displays colors as shades of blue-gray upon a white background, instead of 
the (MUCH) worse looking amber screens. They would also cost about the 
same as amber screens.... 








If Atari chooses to have a detachable keyboard, a smaller version of the 
keyboard used for the Mega ST, maybe having a numeric keypad, which is 
often lacking in Laptop keyboards....they would have the "LAPTOP" market 
in the basket! 





Since the Macintosh became popular, Mac Users have wanted VERY much to 
have a Portable Macintosh, for the same reasons that ST users have wanted 
a Portable ST. One or two of these have shown up, but often they have cost 
around 4500-5000 dollars, near the price of a Mac II. 


The ST is STILL the ONLY computer to emulate a MacIntosh, thanks to Dave 
Small, and since the Portable ST will have a Cartridge Port, it could be 
optionally sold with Spectre 128 (the Mac Emulator made by Dave Small that 
uses 128K ROMs) and advertised to the Mac crowd as the ONLY Portable 
computer that can use Mac software. 








This would cause a VERY large group of people to become ST Users, and 
would give the ST a LOT more credibility and market penetration among 
business users. 





Atari Abagq 


Transputer Futures and the Helios Operating System 





The future of the Abagq seems very interesting. It is obviously aimed at 
Universities and research facilities, who have used Transputers, and other 
parallel processors, mainly as "calculating engines", with a PC as a 
front-end and would more likely use Reduced Instruction Set Computer 
(RISC) Chips in day to day operations. 





Two versions of the Abaq are planned. One will be an add-on for the Mega 
ST, which would handle I/O operations, especially for the 40 Megabyte hard 








disk that will be included, and the other will be a stand-alone machine, 
with a case similar to the Mega ST’s, with an ST motherboard underneath 
the Abaq motherboard. 


The Abagq supports 4 display modes. Mode 0 will support a 1280*960 display 
with either 16 colors or monochrome,and Mode 1 has a 1024*768 display with 
256 colors at the same time. Mode 2 has a 640*400 display, but has two 
separate screens instead of one, for quick, seamless animation. 


When it is released, hopefully December, (with software 
available) the Abaq will have 4 slots, for expansion cards to be made by 
Atari. 











ED. NOTE: We have it on reliable info that Atari plans to release the 
SSS Sos, ABAQ (Transputer) in EUROPE (UK) FIRST!!! 














They will come in two configurations, one a Transputer "Farm" card,having 
4 Transputers in it, and a memory expansion card, having 20 MEGABYTES of 
DRAM chips, resulting in that you could have 84 Megs of Ram, or 17 
Transputers, with all slots filled, or combinations using 3 Farm Cards 


and 1 memory expansion card to have 13 Transputers and 24 Megs of RAM. 

















Since one Transputer runs at 10 Million Instructions Per Second (MIPS), 
having 4 Farm Cards, or 17 T-800’s, would let the Abagq have 170 MIPS of 
computing power, qualifying it as a low-end Supercomputer, for around 15 
to 25 thousand dollars, a cost MUCH lower than the $100,000 computers that 
provide power similar to the Abaq’s fastest configuration. 











Helios Operating System 





The Abag itself is impressive, but its operating system, Helios, makes it 
revolutionary, and the future of the Abagq depends on the popularity 

of Helios. One of its features (and the main goal of Helios) is to allow 
Abags be networked in a way that all of the Transputers in all of the 
machines could potentially be available to ALL users, meaning that if you 
had 4 Abaqs in a network, and 3 Abags were idle, the fourth one could use 
the Transputers in the other three to FURTHER speed up its operations, the 
3 Abaqs acting as "compute servers". 














To make it as familiar as possible, Helios is designed to resemble Unix as 
much as possible. It’s shell is JUST like the Unix C-Shell, using all Unix 
commands, and Helios emulates Unix system calls to the point where MUCH 
Unix software can be ported by little more than recompiling it. Meaning 
that the Unix software on the EST could be easily ported to the Abaq, so 
one computer’s software market could theoretically support the other’s, or 


at least that the Abagq could quickly develop a large software base. 




















The Abaq will use XWINDOWS, implementing GEM on top of it for a graphic 
user interface, adding an entirely new dimension to Unix, and making the 
learning curve for the less-experienced user relatively little. 








Both parallel processors and RISC chips are said to be the future of 
computers, and the Transputer uses both of these technologies. The Abag is 
the first computer to use this chip with a standard operating system, and 
has virtually no competition in computers using either type of chip. It 
is, without a doubt, for the high-end of the market, who would need this 
type of power available, and who would more likely have a use for this 
state of the art technology. 








It will definitely be found in universities and research facilities, and 
will be able to grab this end of the market WAY before any other company 
comes out with a similarly priced (as in the $10,000-$15,000 range) 
computer having any type of parallel processor, perhaps even becoming a 
leading computer in this area. In fact, it might even find its way into 
the segment of the market that the EST is aimed at. 





Helios will help to make the Transputer’s popularity possible, although it 
will not be exclusive to the Abag, as several companies, such as 
supercomputer firms, will also use it in their Transputer machines. 








Even Commodore is working with a German Institute to make a Transputer 
equipped workstation, with an Amiga 2000 to handle I/O operations. This 
does not figure to be any competition, as it will not be out for a while, 
and even now it is reportedly not as good as the Abaq. 





The Atari CD-ROM is supposed to be out at around November, costing 599.95 
retail. At this time, a few software companies will announce CD-ROM 
products for the Atari ST, and it seems that the reason this product has 
been held over so long is that after Atari finished developing it, around 
April, they sent developer kits to certain companies, and it is the wait 
for both these companies and the upcoming Atari Factory that have kept 
the CD-ROM from being put out. 


But they were not idle during this time. They have provided support for 
CD-ROM standards, like High Sierra, and made an interface card, so IBM’s 
and compatibles will be able to use it. 








The PC-5, Atari’s 286 clone, will probably not come out until early next 
year, and when it is out, it won’t sell that well, as IBM clones are now 
a dime a dozen, and NO ONE is likely to buy an Atari PC unless Atari sells 
it for an extremely low price, well below the competing IBM Clone prices, 
combined with spectacular features (VGA, 2 Megs of LIM/EMS RAM) and HEAVY 
advertising, all of which would not make Atari that much profit, and which 


would drain resources that would be best spent on the Atari ST. 


























The AMY chip is still in production, and will probably not be seen in any 
Atari product until late 1989! By that time it will most likely be passe! 








[The Atari Laser Printer has the potential of being popular, but ONLY with 
the Imagen Postscript Module that Atari is planning to include as an 
option. 





It would be MUCH better to increase the price of the SLM 804, by maybe 200 
dollars, but to include the Ultrascript Module as standard. Some people 
need only a "dumb" laser printer, but MANY will want Postscript 
compatibility, almost ALL will want to have both at a good price, and it 
seems that IF Atari can get it out and advertise for it, then Atari might 
still get the market share that they lost by letting it become vaporware. 











ST Game Machine 

Atari IS going to make an ST Game Machine, that will be a stripped down ST 
with Cartridge-based games to be played on an ordinary TV. Look for it to 
hit the markets during the first quarter of 1989. 


If you MUST have the 68000 game machine... 
































NAME IT SOMETHING TOTALLY ALIEN TO THE ST LINE! 
There is VERY little difference between the terms, "ST Game Machine, 
and.. "The ST IS a Game Machine"!!!! 
"TOS has a future" 


A quote, 


IBM has a future, 


This four 


first of 


from Neil 


the year, 











Harris. While this is about as obvious as saying that 





it DOES confirm many things about the future of TOS. 


th revision of TOS that Atari is developing will be out by the 








at a cost of $70.00-90.00. ST REPORT ISSUE # 51 has 
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all the ALLEDGED features listed....graciously provided by Atari. 























EXCEPT ONE IMPORTANT FEATURE FOR HARD DISK SYSTEMS: 











read & write to more than twelve partitions of more than 16mb max per 
partition! 
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— The Resource file 


the fourth installment of ST PRO GEM. We are about to 
mysteries of GEM resource structure, and then use this 
reate some useful utilities for handling dialogs. As 
columns, there is once again a download file. You will 
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find it under the name GEMCL4.C in the ATARI 16-bit Forum (GO PCS-58). 
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While a GEM resource is loaded as a block of binary information, it 
is actually composed of a number of different data structures. These 
structures are linked together in a rather tangled hierarchy. Our 
first job is to map this linkage system. 





The topmost structure in a resource file is the resource header. 
This is an array of words containing the size and offset within the 
resource of the other structures which follow. This information is 
used by GEM during the resource load process, and you should never need 
to access it. (Th resourc header does not appear in the C output 
file; it is generated by the RSCREATE utility if the C file is used to 
recreate the resource.) 


























The next structure of interest is the tree index. This is an array 
of long pointers, each of which addresses the beginning of an object 
tree. Again, you wouldn’t normally access this structure directly. The 
GEM rsrc_gaddr call uses it when finding trees’ addresses. This 
structure is called "rs_trindex" in the C output. 








If you look at the contents of rs_trindex you will notice that the 
values are integers, instead of the pointers I described. What has 
happened is that RCS has converted the pointers to indices into the 
object array. (If you actually used the C file to recreate the resource 


= 


file, then the pointers would be regenerated by RSCREATE.) 

















Now you can follow the link from rs_trindex to the objects stored in 
rs_object. Take (for instance) the second entry in rs_trindex and 
count down that many lines in rs_object. The following line (object) 
should start with a -1l. This indicates that it is the root object of a 
tree. The following objects down to the next root belong to that tree. 
We’ll pass over the details of inter-object linkage for now, leaving it 
for a later column. 























[There are a number of different fields in an object, but right now 
we’ll concentrate on two of them: OB_TYPE and OB_SPEC. The OB_TYPE is 
the field which contains mnemonics like G_STRING and G_BOX indicating 
the type of the object. The OB_SPEC is the only field in each object 
which is a LONG - you can tell it by the L after the number. 























What’s in OB_SPEC depends on the object type, so we need to talk 
about what kinds of objects are available, what you might use them for, 
and finally how they use the OB_SPEC field. 


The box type objects are G_BOX, G_IBOX, and G_BOXCHAR. A G_BOX is 








an opaque rectangle, with an optional border. It’s used to create a 
solid patch of color or pattern on which to place other objects. For 
instance, the background of a dialog is a G_BOX. 


A G_IBOX is a hollow box which has only a border. (If the border 
has no thickness, then the box is "invisible", hence the name.) The 
favorite use for IBOXes is to hold radio buttons. There is also one 
neat trick you can play with an IBOX. If you have more than one object 


(say an image and a string) which you would like to have selected all 
at once, you can insert them in a dialog, then cover them with an IBOX. 
Since the box is transparent, they will show through. If you now make 
the box selectable, clicking on it will highlight the whole area at 
once! 





The G_BOXCHAR is just like a G_BOX, except that a single character 
is drawn in its center. They are mostly used as "control points": the 








FULLER, CLOSER, SIZER, and arrows in GEM windows are BOXCHARS, as are 








the components of the color selection gadgets in the RCS. 


š 








fields conta 


The strin 
G_STRINGs (i 





explanatory text within dialogs. 


the "system f 
We have al 


determined by 


with a border thickness of 


attribute is 
set. 


The OB_SPEC for box type objects is a packed bit array. Its various 


in the background color and pattern, the border thickness 
and color, and the optional character and its color. 





g type objects are G_STRING, G_BUTTON, and G_TITLE. 
n addition to being a bad pun) are for setting up static 


The characters are always written in 





ont": full size, black, with no special effects. 


ready discussed 


many of the uses of G_BUTTONs. They adda 
border around the text. The 


thickness of a G_BUTTON’s border is 


what flags are set for the object. All buttons start out 





one pixel. One pixel is added if the EXIT 





set, and one more is added if the DEFAULT attribute is 





The G_TITLE type is a specially formatted text string used only in 
the title bar of menus. This type is needed to make sure that the 
correctly. The Resource Construction Set automatically 
handles inserting G_TITLEs, so you will seldom use them directly. 


menus redraw 


E 

















In a resource, the OB_SPEC for all string objects is a long pointer 
to a null terminated ASCII string. The string data in the C file is 
shown in the BYTE array rs_strings. Again you will notice that the 





OB_SPECsS in 


To find the string 


the C file have been converted to indices into rs_string. 
which matches the object, take the value of OB_SPEC 








and count down that many lines in rs_strings. The next line is the 
correct string. 





The formatted text object types are G_TEXT, G_BOXTEXT, G_FTEXT, and 


G_FBOXTEXT. 











G_TEXTs are a lot like strings, except that you can 





specify a color, different sizes, and a positioning rule for the text. 








Sinc they 
sparingly to 


G_TEXTs are al 





changed at 
on. 





The G_BOX 
type. These 
their color w 




















require more memory than G_STRINGs, G_TEXTs should be used 
draw attention to important information within a dialog. 
lso useful for automatic centering of dialog text which is 
run-time. I will describe this technique in detail later 





EXT type adds a solid background and border to the G_TEXT 


E 





objects are occasionally used in place of G_BUTTONs when 








The G_FTEX object is an 
specify a constant "template" 
those characters which are to be 





input charac 
rule for G_FT! 











ill draw attention to an important object. 


editable text field. You are able to 
of characters, a validation field for 
typed in, and an initial value for the 


ters. You may also select color, size, and positioning 
EXTs. We’ll discuss text editing at length below. 





The G_FBOXTEXT object, as you might suspect, is the same as G_FTEXT 
with the addition of background and border. This type is seldom used: 
the extra appearance details 


edited. 


The OB_SPI 


EC for a for 





type of structure: a TEDINFO. 


rs_tedinfo. 





Take the OB_SPEC 





count down 


that many entries 


distract attention from the text being 


matted text object is a pointer to yet another 


In the C file, you will find these in 
value from each text type object and 
in xrs_tedinfo, finding the matching 


H 





EDINFO on the next line. Each contains pointers to ASCII strings for 
the template, validation, and initialization. You can find these 
trings in rs_strings, just as above. 





u 


There are also fields for the optional background and border 
details, and for the length of the template and text. As we will see 
when discussing editing, the most important TEDINFO fields are the 
TE_PTEXT pointer to initialized text and the TE_TXTLEN field which 
gives its length. 



































The G_IMAGE object type is the only one of its kind. A G_IMAGE is a 
monochrome bit image. For examples, s the images within the various 
GEM alert boxes. Note that monochrome does not necessarily mean black. 
The image may be any color, but all parts of it are the SAME color. 
G_IMAGES are used as visual cues in dialogs. They are seldom used as 
selectabl items because their entire rectangle is inverted when they 
are clicked. This effect is seldom visually pleasing, particularly if 
the image is colored. 






































G_IMAGE objects have an OB_SPEC which is a pointer to a further 
structure type: the BITBLK. By now, you should guess that you will 
find it in the C file in the array rs_bitblk. The BITBLK contains 
fields describing the height and width of the image in pixels, its 
color,nd it also contains a long pointer to the actual bits which make 
up the image. In the C file, the images ar ncoded as hexadecimal 
words and stored in arrays named IMAGO, IMAG1, and so on. 








The last type of object is the G_ICON. Like the G_IMAGE, the G_ICON 
is a bit image, but it adds a mask array which selects what portions of 
the image will be drawn, as well as an explanatory text field. A 
G_ICON may also specify different colors for its "foreground" pixels 
(the ones that are normally black), and its "background" pixels (which 
are normally white). 








The pictures which you see in Desktop windows are G_ICONs, and so 
are the disks and trashcan on the desktop surface. With the latter you 
will notice the effects of the mask. The desktop shows through right 
up to the edge of the G_ICON, and only the icon itself (not a 
rectangle) is inverted when a disk is selected. 





The OB_SPEC of an icon points to another structure called an 
ICONBLK. It is shown in the C file as rs_iconblk. The ICONBLK 
contains long pointers to its foreground bit array, to the mask bit 
array, and to the ASCII string of explanatory text. It also has the 
foreground and background colors as well as the location of the text 
area from the upper left of the icon. The most common use of G_ICONs 
and ICONBLKs is not in dialogs, instead they are used frequently in 
trees which are built at run-time, such as Desktop windows. Ina 
future article, we will return to a discussion of building such 
"on-the-fly" trees with G_ICONs. 























Now, let’s recap the hierarchy of resource structures: The highest 
level structures are the resource header, and then the tree index. The 
tree index points to the beginning of each object tree. The objects 
making up the tree are of several types, and depending on that type, 
they may contain pointers to ASCII strings, or to TEDINFO, ICONBLK, or 
BITBLK structures. TEDINFOs contain further pointers to strings; 
BITBLKs have pointers to bit images; and ICONBLKs have both. 




















PUTTING IT TO WORK 
The most common situations requiring you to understand resource 
structures involve the use of text and editable text objects in 
dialogs. We’ll look at two such techniques. 











Often an application requires two or more dialogs which are very 
similar except for one or two title lines. In this circumstance, you 
can save a good deal of resource space by building only one dialog, and 
changing the title at run time. 





It is easy to go wrong with this practice, however, because th 
obvious tactic of using a G_STRING and writing over its text at run 
time can go wrong. The first problem is that you must know in advance 
the longest title to be used, and put a string that long into the 
resource. If you don’t you will damage other objects in the resource 
as you copy in characters. The other problem is that a G_STRING is 
always drawn at the same place in a dialog. If the length of the title 

changes from time to time, the dialog will have an unbalanced and 
sloppy appearance. 














A better way to do this is to exploit the G_TEXT object type, and 








the TEDINFO structure. The set_text() routine in the download shows 
how. The parameters provided are the tr address, the object number, 
and the 32-bit address of the string to be substituted. For this to 








work, the object referenced should be defined as a G_TEXT type object. 
Additionally, the Centered text type should be chosen, and the object 
should have been "stretched" so that it fills the dialog box from side 
to side. 








In the code, the first action is to get the OB_SPEC from the object 
which was referenced. Since we know that the object is a G_TEXT, the 
OB_SPEC must point to a TEDINFO. We need to change two fields in the 
EDINFO. The TE_PTEXT field is the pointer to the actual string to be 


displayed; we replace it with the address of our new string. The 

































































EF TXTLEN field is loaded with the new string’s length. Since the 
Centered attribute was specified for the object, changing the TE_TXTLEN 
will cause the string to be correctly positioned in the middle of the 
dialog! 








Editing text also requires working with the TEDINFO structure. One 
way of doing this is shown in the download. The object to be used 
(EDITOBJ) is assumed to be a G_FTEXT or G_FBOXTEXT. Since we will 
replace the initialized text at run time, that field may be left empty 
when building the object in the RCS. 





























The basic trick of this code is to point the TEDINFO’s TE_PTEXT at a 
string which is defined in your code’s local stack. The advantages of 
this technique are that you save resource space, save static data by 
putting the string in reusable stack memory, and automatically create a 
scratch string which may be discarded if the dialog is cancelled. 

















The text string shown is arbitrarily 41 characters long. You should 
give yours a length equal to the number of blanks in the object’s 
template field plus one. Note that the code is shown as a segment, 
rather than a subroutine. This is required because the text string 
must be allocated within the context of the dialog handling routine 
itself, rather than a routine which it calls! 








After the tree address is found, the code proceeds to find the 

















TEDINFO and modify its TE_PTEXT as described above. However, the 
length which is inserted into TE_TXTLEN must be the maximum string 
length, including the null! 




















The final line of code inserts a null into the first character of 
the uninitialized string. This will produce an empty editing field 
when the dialog is displayed. If there is an existing value for the 
object, you should instead use strcpy() to move it into text[]. Once 
the dialog is complete, you should check its final status as described 
in the last article. If an "OK" button was clicked, you will then use 
strcpy() to move the value in text[] back to its static location. 











Although I prefer this method of handling editable text, another 
method deserves mention also. This procedure allocates a full length 
text string of blanks when creating the editable object in the RCS. At 
run-time, the TE_PTEXT link is followed to find this string’s location 
in the resource, and any pre-existing value is copied in. After the 
dialog is run, the resulting value is copied back out if the dialog 


completed successfully. 























Note that in both editing techniques a copy of the current string 
value is kept within the application’s data area. Threading the 
resource whenever you need to check a string’s value is extremely 
wasteful. 





One final note on editable text objects: GEM’s editor uses the 
commercial at sign ’@’ as a "meta-character". If it is the first byte 
of the initialized text, then the field is displayed blank no matter 
what follows. This can be useful, but is sometimes confusing when a 
user in all innocence enters an @ and has his text disappear the next 
time the dialog is drawn! 

















LETTERS, WE GET LETTERS 


























The Feedback section on ANTIC ST ONLINE is now functional and is 
producing a gratifying volume of response. A number of requests were 
made for topics such as ST hardware and ST BASIC which are beyond the 
intended scope of this column. These have been referred to ANTIC’s 
editorial staff for action. 








So many good GEM questions were received that I will devote part of 
the next column to answering several of general interest. Also, your 
requests have resulted in scheduling future columns on VDI text output 
and on the principles (or mythology) of designing GEM application 
interfaces. Finally, a tip of the hat to the anonymous reader who 
suggested including the actual definitions of all macro symbols, so 
that those without the appropriate H files can follow along. Asa 
result of this suggestion, the definitions for this column and the 
previous three are included at the end of the download. Future 
articles will continue this practice. 











STRAW POLL! 

I’d like to make a practice of using the Feedback to get your 
opinions on the column’s format. As a first trial, I’d like to know 
your feelings about my use of "portability macros" in the sample code. 
These macros, LLGET for example, are used for compatibility between 68K 
GEM systems like the ST, and Intel based systems like the IBM PC. This 








may be important to many developers. On the other hand, omitting them 
results in more natural looking C code. For instance, in the download 
you will find a second version of set_text() as described above, but 
without the portability macros. So, I would like to know if you think 
we should (A) Keep the macros - portability is important to serious 
developers, (B) Get rid of them - who cares about Intel chips anyway, 
or (C) Who cares? I’ll tally the votes in two weeks and announce the 
results here. 











STAY TUNED! 


As well as answers to feedback questions, the next column will 
discuss how GEM objects are linked to form trees, and how to use AES 
calls and your own code to manipulate them for fun and profit. In the 
following installment, we’ll look at the VDI raster operations (also 
known as "blit" functions). 























>>> >>>>>>>>>>>>>>>>>>>>>> Sample C output file from RCS <<<<<<<<<<<<<<<<<< 


/* (Comments added) * / 
BYTE *rs_strings[] = { /* ASCII data Bf 
"Title String", 


" 








Exit", 
"Centered Text", 


"n 
£ 


"n 
T 


" Tokyo " i 


ww 
T 


"Time: : : y 


a 


9999991% 


"n 
T 
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"999999", 
"New York"}; 


WORD IMAGO { /* Bitmap for G_IMAGE */ 
Ox7FF, OxFFFF, OxFF80, 0xC00, 
0x0, OxCO, Ox183F, OxFO3F, 
OxF060, Ox187F, OxF860, 0x1860, 
Ox187F, OxF860, Ox1860, Ox187F, 
OxF860, 0x1860, Ox187F, OxF860, 
0x1860, Ox187F, OxF860, 0x1860, 
Ox187F, OxF860, Ox1860, Ox187F, 
OxF860, 0x1860, Ox187F, OxF860, 
0x1860, Ox187F, OxF860, 0x1860, 
Ox187F, OxF860, Ox1860, Ox187F, 
OxF860, 0x1860, Ox183F, OxFO3F, 
OxF060, 0xC00, 0x0, 0xCO0, 
Ox7FF, OxFFFF, OxFF80, 0x0, 
0x0, Ox0, Ox3F30, OxC787, 
Ox8FEO, OxC39, OxCCCC, OxCCOO, 
OxC36, OxCFCC, OxF80, OxC30, 
OxCCCD, OxCC0O0, Ox3F30, OxCCC7, 
OxCFEO, Ox0, Ox0, Ox0}; 





wu 








WORD IMAG1[] = { /* Mask for first icon */ 


0x0, 0x0, 0x0, 


Ox7FFE, 0x0, O0x1F, 





0x0, 


OxFC00, OxFF, OxFFFF, 
OxFFCO, OxFFF, 

Ox3FFF, OxFFFF, 
OxFFFF, OxFFFE, 


Ox3FF, OxFFFF, 
OxFFFF, OxFFFO, 
OxFFFC, Ox7FFF, 


OxFFFF, 


OxFFOO, 








OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFFF, Ox7FFF, 








OxFFFF, OxFFFE, 
OxFFFC, OxFFF, 
Ox3FF, OxFFFF, 
OxFFFF, OxFFO0O0, 


Ox3FFF, OxFFFF, 
OxFFFF, OxFFFO, 
OxFFCO, OxFF, 


Oxl1F, 


OxF800, Ox0, Ox7FFE, 


WORD IMAG2[] = 
0x0, 0x0, 0x0, 


Ox3FFC, 0x0, OxF, 


{ 





0x0, 


OxFO00, 0x78, 0x180, 
0x180, 0x180, 0x180, 
0x1c00, 0x6, 
0x38, 0x3000, Ox18C, 

0x306, 


0x180, 0xC060, 


0x60C0, 0x198, 


0x1B0, 0x6, 0x4000, 
0x2, 0xC000, 0x1cC0, 


OxCFCO, 0x180, 


0x0, 0x3, 0x4000, 
0x2, 0x6000, 0x0, 
0x60C0, 0x0, 0x306, 
0x0, 0xC, 0x1cC00, 
0x38, 0x603, 0x180, 


0x3F3, 


0x180, 0x180, 0x180, 


0x180, 0x1E00, 





OxF, 


OxF000, Ox0, Ox3FFC, 


WORD IMAG3[] = 
0x0, 0x0, 0x0, 


Ox7FFE, 0x0, O0Ox1F, 





{ 


0x0, 


OxFCOO, OxFF, OxFFFF, 
OxFFCO, OxFFF, 

Ox3FFF, OxFFFF, 
OxFFFF, OxFFFE, 


Ox3FF, OxFFFF, 
OxFFFF, OxFFFO, 
OxFFFC, Ox7FFF, 


OxFFFF, 
0x0}; 


0xc003, 


0x1E00, 
0x603, 





OxC, 
0x6000, 


Ox1E0O, 
0x3, 





OxC000, 


0x0, 
0x6, 
0x3000, 
0x0, 
OxC060, 


0x78, 


0xc003, 


0x0}; 


OxFFFF, 


OxFFOO, 








OxFFFF, OxFFFF, 


OxFFE 


F, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFE 


F, OxFFEFF, 





OxFFFF, OxFFFF, 


OxFFE 


F, OxFFFF, 





OxFFFF, OxFFFF, 


OXxFFE 


F, OxFFEFF, 





OxFFFF, OxFFFF, 


OxFFE 


F, OxFFFF, 





OxFFFF, OxFFFF, 


OxFFE 


F, OxFFEFF, 





OxFFFF, OxFFFF, 


OxFFE 


F, Ox7FEFF, 








OxFFFF, OxFFFE, 
OxFFFC, OxFFF, 
Ox3FF, OxFFFF, 
OxFFFF, OxFFO0O, 


Ox3FE 


F, OxFFFF, 


OxFFFF, OxFFFO, 
OxFFCO, OxFF, 


ORLE; 





OxF800, Ox0, 0x7FFE, 


WORD IMAG4[] = 


{ 


OxFFFF, 
0x0}; 


/* Data for first icon 


/* Mask for second icon */ 


/* Data for second icon */ 


xy 










































































































































































0x0, 0x0, 0x0, 0x0, 

Ox3FFC, 0X07- OXE; 0XC00S; 

OxFO00, 0x78, 0x180, 0x1E00, 

0x180, 0x180, 0x180, 0x603, 

0x180, 0xC060, 0x1C00, 0x6, 

0x38, 0x3000, Ox18C, OxC, 

Ox60C0O, 0x198, 0x306, 0x6000, 

0x1B0, 0x6, 0x4000, 0x1E0, 

0x2, OxC000, Ox1CO, 0x3, 

OxCFCO, O0x180, Ox3F3, OxC000, 

0x0, 0x3, 0x4000, 0x0, 

0x2, 0x6000, 0x0, 0x6, 

Ox60C0O, 0x0, 0x306, 0x3000, 

0x0, 0xC, Ox1C00, 0x0, 

0x38, 0x603, 0x180, OxC060, 

0x180, 0x180, 0x180, 0x78, 

0x180, 0x1E00, OxF, OxC003, 

OxFO00, Ox0, Ox3FFC, 0x0}; 

LONG rs_frstr[] = { /* Free string index - unused */ 

0}; 

BITBLK rs_bitblk[] = { /* First entry is index to image data 

OL, 6, 24, 0, O, O}; 

LONG rs_frimg[] = { /* Fr image index unused */ 

0}; 

ICONBLK rs_iconblk[] = { 

Thy Qh, LOT; -40.96;, 00% \0.,-0;,;48724,. 9;.24,.30%8; /* First pointer is mask 

3L, 4L, 17L, 4864,0,0, 0,0,48,24, 0,24,48,8}; /* Second is data, third 
/* is to title string 

TEDINFO rs_tedinfo[] = { 

2157. Sigs Aly. -3y Gr 23 (0xX1180,-0x0;, =p Ly L /* First pointer is text 

7L; Shy, 9b, 3; 6, 2, 0x2072, 0x0; -3; 11,1, /* Second is template 

11L, 12L, 13L, 3, 6, O, Ox1180, Ox0, -1, 1,15, /* Third is validation 

14L, 15L, 16L, 3, 6, 1, 0x1173, 0x0, 0, 1,17}; 

OBJECT rs_object[] = { 

-1, 1, 3, G_BOX, O-LINED, 0x21100L, 0,0, 18,12, /* Pointers are to: 

2, -1, -1, G_STRING, NONE, NORMAL, Ox0L, 3,1, 12,1, /* rs_strings 

3, -1, -1, G_BUTTON, 0x7, NORMAL, Ox1L, 5,9, 8,1, /* rs_strings 

0, 4, 4, G_BOX, NONE, NORMAL, OxFF1172L, 3,3, 12,5, 

3, -1, -1, G_IMAGE, LASTOB, NORMAL, OxOL, 3,1, 6,3, /* rs_bitblk 

-1, 1, 6, G_BOX, NONE, O-LINED, 0x21100L, 0,0, 23,12, 

2, -1, -1, G_TEXT, NONE, NORMAL, OxOL, 0,1, 23,1, /* vs_tedinfo 

6, 3, 5, G_IBOX, NONE, NORMAL, 0x1100L, 6,3, 11,5, 

4, -1, -1, G_BUTTON, 0x11, NORMAL, Ox5L, 0,0, 11,1, /* rs_strings 

5, -1, -1, G_BUTTON, 0x11, NORMAL, Ox6L, 0,2, 11,1, /* rs_strings 

2, -1, -1, G_BOXCHAR, 0x11, NORMAL, 0x43FF1400L, 0,4, 11,1, 

0, -1, -1, G_BOXTEXT, 0x27, NORM, OxlL, 5,9, 13,1, /* rs_tedinfo 

-1, 1, 3, G BOX, NONE, OUTLINED, 0x21100L, 0,0, 32,11, 

2, -1, -1, G_ICON, NONE, NORMAL, Ox0L, 4,1, 6,4, /* vs_iconblk 

3, -l, -1, G_FTEXT, EDIT, NORM, 0x2L, 12,2, 14,1, /* rs_tedinfo 

0, 4, 4, G_FBOXTEXT, OxE, NORMAL, Ox3L, 3,5, 25,4, /* rs_tedinfo 

3, -1, -1, G_ICON, LASTOB, NORMAL, Ox1L, 1,0, 6,4}; /* rs_iconblk 

LONG rs_trindex[] = { /* Points to start of trees in */ 





/* rs_object 


$ 


Ay, 


*/ 
Ay, 
x 


*/ 
KJ 
*/ 


*/ 
Ai, 
£7 


*/ 


*/ 


*/ 
Ai. 


ay, 


Ai, 
*/ 
Ay, 
*/ 


12L}; 


struct foobar { /* Temporary structure used by Ay. 
WORD dummy; /* RSCREATE when setting up image */ 
WORD *image; /* pointers. E 
} rs_imdope[] = { 
&IMAGO[0], 
&IMAG1[0 
&IMAG2 [0 
[0 
[0 














` 


` 


T 


&IMAG3 
, &IMAG4 


` 


O OO OO 
~ 


] 
]l, 
ep 
l1}; 


/* Counts of structures defined */ 
























































define NUM_STRINGS 18 
define NUM_FRSTR 0 
define NUM_IMAGES 5 
define NUM_BB 1 
define NUM_FRIMG 0 
define NUM_IB 2 
define NUM_TI 4 
define NUM_OBS 17 
define NUM_TREE 3 
BYTE pname[] = "DEMO.RSC"; 








>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Title change utility <<<<<<<<<<<<<<<<<<<<< 
































VOID 
set_text (tree, obj, str) 
LONG tree, str; 
WORD obj; 
{ 
LONG obspec; 
obspec = LLGET(OB_SPEC (obj) ); /* Get TEDINFO address */ 
L\LSET (TE_PTEXT (obspec), str); /* Set new text pointer */ 
WSET (TE_TXTLEN (obspec), LSTRLEN(str)); /* Set new length * / 


























} 


>>>>>>>>>>>>>>>>>>>>>> Text edit code segment <<<<<<<<<<<<<<<<<<<<<<<<<< 

































































LONG tree, obspec; 

BYTE text [41]; 

rsrc_gaddr(R_TREE, DIALOG, &tree); /* Get tree address */ 
obspec = LLGET(OB_SPEC (EDITOBJ) ) ; /* Get TEDINFO address */ 
.LSET (TE_PTEXT (obspec), ADDR(str)); /* Set new text pointer */ 
WSET (TE_TXTLEN (obspec), 41); /* Set max length * / 
text [0] = ’\0'; /* Make empty string * / 











>>>>>>>>>>>>>>>>>>>> Sample 68K only source code <<<<<<<<<<<<<<<<<<<<<< 


VOID 

set_text (tree, obj, str) 
OBJECT *x*tree; 
WORD obj; 
BYTE *Str; 





{ 
TEDINFO *obspec; 














obspec = (TEDINFO *) (tree + obj) ->ob_spec; 

/* Get TEDINFO address */ 
obspec->te_ptext = str; /* Set new text pointer */ 
obspec->te_txtlen = strlen(str); /* Set new length */ 


} 


>>>>>>>>>>>>>>>>>>>>>>>>>>>> Symbol definitions <<<<<<<<<<<<<<<<<<<<<<<<< 


/* Window parts */ 


























































































































































































































define NAME 0x0001 
define CLOSER 0x0002 
define FULLER 0x0004 
define MOVER 0x0008 
define INFO 0x0010 
define SIZER 0x0020 
define UPARROW 0x0040 
define DNARROW 0x0080 
define VSLIDE 0x0100 
define LFARROW 0x0200 
define RTARROW 0x0400 
define HSLIDE 0x0800 
define WF_KIND 1 /* wind_get/set parameters */ 
define WF_NAME 2 
define WF_INFO 3 
define WF_WXYWH 4 
define WF_CXYWH 5 
define WF_PXYWH 6 
define WF_FXYWH 7 
define WF_HSLIDE 8 
define WF_VSLIDE 9 
define WF_TOP 10 
define WF_FIRSTXYWH 11 
define WF_NEXTXYWH 12 
define WF_NEWDESK 14 
define WF_HSLSIZ 15 
define WF_VSLSIZ 16 
/* window messages * / 
define WM_REDRAW 20 
define WM_TOPPED 21 
define WM_CLOSED 22 
define WM_FULLED 23 
define WM_ARROWED 24 
define WM_HSLID 25 
define WM_VSLID 26 
define WM_SIZED 27 
define WM_MOVED 28 
define WM_NEWTOP 29 
/* arrow messages Bef 
define WA_UPPAGE 0 
define WA_DNPAGE 1 
define WA_UPLINE 2 
define WA_DNLINE 3 
define WA_LFPAGE 4 
define WA_RTPAGE 5 
define WA_LFLINE 6 




















































































































































































































define WA_RTLINE 7 
define R_TREE 0 /* Redraw definitions * / 
define ROOT 0 
define MAX_DEPTH 8 
/* update flags * / 
defin END_UPDATE 0 
defin BEG_UPDATE 1 
defin END_MCTRL 2 
defin BEG_MCTRL 3 
/* Mouse state changes * / 
define M_OFF 256 
define M_ON 257 
/* Object flags * / 
define NONE 0x0 
define SELECTABLE 0x1 
define DEFAULT 0x2 
define EXIT 0x4 
define EDITABLE 0x8 
define RBUTTON 0x10 
/* Object states * / 
define SELECTED 0x1 
define CROSSED 0x2 
define CHECKED 0x4 
define DISABLED 0x8 
define OUTLINED 0x10 
define SHADOWED 0x20 
define G_BOX 20 
define G_TEX 21 
define G_BOXTEXT 22 
define G_IMAGE 23 
define G_IBOX 25 
define G_BUTTON 26 
define G_BOXCHAR 27 
define G_STRING 28 
define G_FTEX 29 
define G_FBOXTEXT 30 
define G_ICON 31 
define G_TITLE 32 
/* Data structures * / 
typedef struct grect 
{ 
int gox; 
int g_y; 
int g_w; 
int g_h; 
} GRECT; 
typedef struct object 
{ 
int ob_next; /* -> object’s next sibling 
int ob_head; /* -> head of object’s children 
int ob_tail; /* -> tail of object’s children 
unsigned int ob_type; /* type of object- BOX, CHAR,... 
unsigned int ob_flags; /* flags 
unsigned int ob_state; /* state- SELECTED, OPEN, 
long ob_spec; /* "out"- -> anything else 
int ob_x; /* upper left corner of object 
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int ob_y; /* upper left corner of object $ 
int ob_width; /* width of obj */ 
int ob_height; /* height of obj E 
} OBJECT; 





typedef struct text_edinfo 
{ 











long te_ptext; /* ptr to text (must be 1st) */ 
long te_ptmplt; /* ptr to template Ks), 
long te_pvalid; /* ptr to validation chrs. xy 
int te_font; /* font ef 
int te_junkl; /* junk word */ 
int te_just; /* justification- left, right... */ 
int te_color; /* color information word coy 
int te_junk2; /* junk word wf 
int te_thickness; /* border thickness */ 
int te_txtlen; /* length of text string * / 
int te_tmplen; /* length of template string ei 


} TEDINFO; 





/* "Portable" data definitions */ 





























































































































define OB_NEXT (x) (tree + (x) * sizeof (OBJECT) + 0) 
define OB HEAD (x) (tree + (x) * sizeof (OBJECT) + 2) 
define OB_TAIL (x) (tree + (x) * sizeof (OBJECT) + 4) 
define OB_ TYPE (x) (tree + (x) * sizeof (OBJECT) + 6) 
define OB_FLAGS (x) (tree + (x) * sizeof (OBJECT) + 8) 
define OB_STATE (x) (tree + (x) * sizeof (OBJECT) + 10) 
define OB_SPEC (x) (tree + (x) * sizeof (OBJECT) + 12) 
define OB_X(x) (tree + (x) * sizeof (OBJECT) + 16) 
define OB_Y(x) (tree + (x) * sizeof (OBJECT) + 18) 
define OB_WIDTH (x) (tree + (x) * sizeof (OBJECT) + 20) 
define OB_HEIGHT(x) (tree + (x) * sizeof (OBJECT) + 22) 
defin KE PTEXT (x) (x) 

defin E TXTLEN (x) (x + 24) 























SHAKESPEARE and FUJI 














by Rex Reade 


"All the world is a stage ........ "Shakespeare was perhaps more a prophet 
than we would like to admit or is it that human behavior hasn’t really 
changed all that much from his era to ours? These are heavy points to 
ponder. Seemingly, the ideals of that era and the upcoming events in the 
Atari community are indeed similar.... 


Will Atari, when they go 





"CENTER STAGE" on Sept 26, 1988 ~ CIS 9pm EST 




















and before the whole world, act like the "Wizard of Oz"! All noise and 
self righteous justification. 


Or, 

Will they follow the simple and uninvolved method of telling the truth 
without all the corporate fluff and fodder. How refreshing that would be 
after the "announcements and statements" of the last few weeks. Hopefully 


they will take the latter course. 


We realize that the leadership of Atari is only human ...DO THEY? 





Atari will have the "Golden Opportunity" to practically right all the 
wrongs and reinstill the enthusiastic support of it’s userbase. Of 
course, it is up to them and them alone. As far as we are concerned, what 
Atari does with this upcoming conference (Sept.26 - CIS) will tell the 
whole world what they think of the US Userbase and it’s future. 














One thing is certain, Atari can make the conference a marvelous event that 
will have considerable bearing on the future of the Atari in the United 
States Marketplace. 











Folks, consider these questions..Feel free to use them in the conference 





1 - Why Europe first, when you got your start here in the USA??? 





2 —- We in the USA have more bux to spend why do you ship to Europe? 


3 - Is the pursuit of profits so strong as to require the 
administration of a "death blow" to the US Market? 


4 - What are the real plans for the US market, if any and do you 
plan to use a different name on the new line of computers? 


5 - If the STGS is a reality, will you ensure the "protection" of 
the integrity of the ST line by a name change etc..? 


We cannot under any circumstances provide all the questions nor would we 
even try. We have included some samples that will make ’em think before 
they leap <grin> ....Do not forget to ask about FEDERATED and the deal 
there for the users and the INDEPENDANT DEALERS. 









































Above all else, please refrain from the hysterical "hero worship" we have 
seen in the past...ask sensible questions, avoid personal attacks.. (this 
means against Atari and it’s people) they ARE Atari ...... let all the 
issues concerning Atari and creating unrest in your area be brought 
forward. 








REMEMBER, ATARI USERS.... 














E 





THIS IS YOUR GOLDEN OPPORTUNITY TOO! 





The Presidential Conference 


September 26, 1988 -- 9 PM; EST 








COMP—-U-SERVE 











ps: If you are not a user of CIS, NOW is the time to take advantage of the 
special offer and join CIS. (the information is in this issue) 





Garbage-On-The-Line 


The Prince of Darkness Comes Forward 








by Linda Woodworth 


"YO, Cd. TE 6. Mex ies Satan! You Summonded?" 


A little over a month ago, the FoReM F Netting BBSs started "getting hit" 
by a mysterious phantom Mailer. HellFire BBS Node 666. This is easy 

enough to do, and when talk began in the SysOp Bases, I became intrigued. 
Say eet EEEE EE E Who was this Satan of Node 666 ?? 











THEN, an FNetted/FMail file came thru the Net to all SysOps. SEREG.ARC. 

















Satan had cracked the protection scheme on Jon Radoff’s on line game, 
Space Empire. It gave the ability to run Space Empire to it’s full 
abilities. Many SysOp’s were upset... some were amused, all types of 
comments were to be heard. I became even more fascinated. 





Did Satan actually run a Board, was he "one of us", many questions and 
why’s began running around. What were his reasons for hitting bords 
randomly in the night. Time was running out... the New Mailer was going 
into effect, and unless he was a registered SysOp with Dave Chiquelin, 
<the Mailer author> we would lose our communication link. A message came 
through saying Satan was "going after the New Mailer next". I sent out a 
message to all nodes, asking him to log on my board so we could talk. A 
few thought I was nuts, and was making a pact with the devil. Is this 
why I had a monitor die ?? 








About two days after the message went out, Satan logged on. In fact, I 
had a couple Satan’s. But I had the one I wanted... I asked his 
permission to do this interview, and we began a fasinating dialog. I also 
called the number he left upon logon. 1-800-HELFIRE. No connection. 











The first set of questions I asked Satan, was if he ran a board, and if 
the Space Empire cracker had a trojan in it <like some had said>. NO to 
both. Satan set up HellFire as a "mock" BBS, implemented the Mailer to 
call the boards. The first thing Satan said to me was this... 











"HellFire BBS is as real as a 3 dollar bill, the 666 is just something I 
came up with to fit in with the SATAN bit. I don’t really worship the 
devil or anything. It’s just somethin’ controversial and gets people all 














"fired up". I didn’t have any real purpose behind the SE ripoff program 
other than to prove it could be done. As for the long sex file, that 
wasn’t all mine. A few friends helped to ’come’ up with some ideas for 
Tt! 





A little devilish humor ?? They had some good ideas too..... <grin> 











There was NO Trojan in the SEREG, as I had that checked out... 





Satan’s had his ST for apx. 10 months, and he told me he "liked freaking 
people out and trying to cause things such as the FNet to deviate from the 
normal -- the NEW Mailer provides a new challenge for me..." 





<the new Mailer provides a challenge for all SysOps too - grin> 


I felt like I was straddling the fence. Talking with Satan on one hand, 
and Dave Chiquelin, on the other. I really was selling my soul... but to 
who ?? <grin> Hi Boris !! Thanks for trusting me with the background 
information on the protection for the New Mailer. 





Satan continued to log on for the next two weeks. I didn’t get to find 
out all the information I wanted... but life isn’t over, yet. Perhaps I 
will do a follow up sometime. I hope he got some satisfaction out of the 


deviation from the norm, and puts his twenty years and obvious talent to 
use to help us all. 


Satan had his turn at the limelight, and yes, I am giving him more... but 
I’ve talked enough with him to know he isn’t after doing trojan’s or 
considerable continued mayhem. I must give the devil his due, as I hada 
problem on The Chip, and he took the time to let me know. <Thank You> 

I have the feeling he is a person doing some experimenting with life. His 
messages were to the point, consistant, and full of humor. 





Jon Radoff is upset however. But, then we could get into the "cast the 
first stone" type of thing. Right now, I’m not going to touch that one 
with a ten foot pole. It COULD raise the devil! 





I did find out Satan had no pact on my soul, as he has enough souls to 
last a few centuries. Seems like there were a lot of souls for sale a 
few years ago. Hmmm... I had yet another monitor go out just last night!! 





The last time I heard from Satan was on Sept 6, 1988 at 9:08 PM <MDT> 











"Well, my days at mayhem are over. No more FNetting from the mysterious 
HellFire BBS, no more cracking. I have accomplished what I wanted, to 
make waves. Some major tidal waves. Now that that’s done, I don’t need 


mysterious fnet mail or code breaking programs." 


The Satanic Force was exciting and I thank all SysOp’s who allowed my 
messages to remain on their boards. 














OF SPECIAL NOTE: 


>From: (David Small) 

Subject: New Data Pacific Newsletter 
Keywords: magic sac, dp, translator 
Date: 26 Aug 88 





Data Pacific has released a new newsletter in the last few days that 
deserves a warning. It’s full of distortions, half-truths, is misleading, 
and contains some flat false information. It’s going to confuse a lot 

of people, so I’m trying to spread the word. 











For instance, the newsletter contains columns from people who no 
longer work at dP (most of dP’s staff quit in March-April, including me). 
It talks of a new tech person, "Mike", who does not exist and who always 
has been a pseduonym for Joel when taking tech calls. 





More subtly, the newsletter implies that dP is having me look into 
a 128K ROM version of the Magic Sac. This is false; I have nothing to do 
with Data Pacific(except for one contract job -- version 6.1 of Magic Sac, 
in exchange for a LaserWriter). dP (Joel) agreed long ago to stop using 
my name to try to sell their products; they’ve broken their promise. 


The newsletter says Dan Moore (dlm@druhi here) "worked overtime" 
to produce Mover 1.7. The truth is, Dan did Mover 1.7 for a flat $150 fee 
in July. He was paid by check after dropping off the disk; his bank later 
told him that Joel *had stopped the check*. In short, dP is selling a 
version of Mover 1.7 that they flat stole from Dan. 


If you appreciate any of the contributions Dan has made to the ST world, 
such as the Twister disk format, Meg-a-minute backup, Protect accessory, 
and others, you could return him the favor by refusing to buy dP’s disk 
until they remove Mover 1.7 from it, and letting them know why. Dan’s had 
a rough month; he broke his hand recently, and is in a cast to his elbow 
(any get well cards sent via email would be greatly appreciated), 
by the way. 





In my opinion, DP is attempting to present an image that things 
are as they were during the good days, while selling off as much stock as 








possible, with this newsletter then they’re getting out. How else to 
explain them putting Apple’s own Switcher and FONT/DA Mover on their 
"public domain" disk -- other than dP isn’t planning on being around long 


enough for Apple to catch them (and rightfully so; Hertzfeld worked hard 
on Switcher). 


I’d like it made clear I have nothing to do with Data Pacific anymore; I 
answer dP related questions out of courtesy to my old customers, and 
nothing more. The same is true for Dan Moore. The tactics Data Pacific is 
stooping to, in my opinion, to milk a little more money from the Magic Sac 
before folding up are shoddy in the extreme, and I think it’s a shame my 
name is still associated with this company. Hence, this note. 


As for me, I have a new company, Gadgets By Small, Inc, and we’re planning 
on releasing our first product (the Spectre 128) on Sept. 16, at the Atari 
Glendale Atarifest show. Since dP has broken it’s word (again) to give me 
access to their customer mailing list, which I built, I can’t put out the 
word about the Spectre 128 upgrade to the Magic Sac except by the 
networks. 


For the record, and to answer a previous questions, I left Data Pacific 
in March of this year, when it became clear that (a) Joel was not going 
to honor our agreements, and (b) when I found out the FCC number being 
put on the Translator units had been forged, and Joel had no plans to ever 
[having the] FCC certify the unit. Believe me, I want no part of trying to 
slip one past the FCC. (Every Translator unit shipped bears this same false 
number.) 
I wouldn’t be party to this; neither would Dan, when he heard. (Thanks 
to our friends from Supra for checking the number at the FCC BBS and 
telling us what had happened!) 





I plan to carry on support of dP buyers with my new company, here and 
on other networks, as a courtesy to the people who shelled out money for 
the Magic Sac, but via a new company (Gadgets), as well as "push the 
envelope" further on Mac emulation with the Spectre 128 product. I don’t 
want to advertise here on the net publicly; please drop me email privately 
if you’re interested (hplabs!well!dsmall or dsmall@well); I don’t think 
the local community would appreciate a few hundred "Yes, please send m 
info" notes here in comp.sys.atari.st. 




















Thanks for reading a rather long note; I plead that I’m used to getting 
paid by wordcount <grin>. 


-—- Thanks, Dave Small 
Gadgets by Small, Inc. 








ST REPORT CONFIDENTIAL 














Sunnyvale CA. Seems Atari wants ALL the usergroups to re-register, it is 

Se a good idea, if you need the forms, call Cindy at Atari. 
Sig Hartmann has the right idea, "Let’s be straight forward 
and only human with the users". Great Idea! 


Sunnyvale CA. Sam Tramiel, President of Atari along with Sig Hartmann 

Hae Vice President of Atari will hold a formal conference on 
Compuserve in the Convention Center Sept. 26 9pm EST all 
interested parties are invited to attend. 




















Houston TX. Still NO AGREEMENT on the site for the new Atari Factory... 





Glendale CA. Data-Pacific, obvious by their absence, is history, 

Seo Sa according to an informal survey conducted among spectators 
at the show. Spectre 128 was a SMASH HIT at it’s 
introduction and GBS had a sell-out show! Codehead 
Software was another major attraction showing G+PLUS and 
MASTERDESK along with Charles and John. Reportedly they 
had nothing left to sell either. Great news guys! 

















Reading PA. According to a prominent mail order house Soft Logic is 
Sea Se shooting for an end of the month release of the 
"Professional" version of it’s DTP package. Hope so, cause 


this mail order 


house sez if not, 





they DROP the whole line! 











Ontario CAN. Seems there is a Demo of "Calamus" making the rounds, only 
aps ee problem is ...it’s in GERMAN!! 
HIS WEEK’S QUOTABLE QUOTE 





























[There is always an easy answer to every human problem..... 


NEAT, PLAUSIBLE and WRONG! 








T 
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